The present invention relates to event loop optimization, and more specifically to event loop optimization for Node.js through event ordering.
There are two approaches to handling large numbers of transactions within runtimes. One approach uses multiple threads to do work in parallel and synchronization techniques to co-ordinate between those threads.
The other approach uses an “event-loop”, a programming construct that waits for and dispatches events or messages in a program, where a single thread (or a small number of independent event-loops) processes the work for the event-loop. In the event-loop loop, events become ready and at some interval, and the single thread processes those events. In the processing for each interval, the single thread invokes the function registered for each ready event until all events have been serviced.
Commonly, in existing implementations, for example Node.js/libuv, for example, the order the events are processed is not specified and is simply a result of the implementation choices made in the operating system and/or the timing at which the events became ready.
Node.js is a single-threaded application, which can support concurrency via events and callbacks. The node depends on multiple libraries. One of those libraries is Libuv, which handles the queueing and processing of asynchronous events. Libuv utilizes as much of the underlying functionality available from the operating system's kernel as possible. When possible, requests are delegated to and handled by the operating system. Incoming connections are queued by the system until they can be handled by libuv/Node.js.
Many Node.js APIs are asynchronous and can therefore use async function calls to maintain concurrency. Generally, a Node.js application is initiated by setting up a number of events and listeners waiting on those events. As events occur as signaled by the operating system, the functions registered as listeners are invoked. These functions may generate responses, register additional listeners or remove listeners. The application continues to run until there are no more move events registered in the event loop at which point the application terminates.